home *** CD-ROM | disk | FTP | other *** search
/ Windows Expert / Windows Expert.iso / windownt / rcsdoc.zip / CI.TXT next >
Text File  |  1993-08-09  |  13KB  |  261 lines
  1.  
  2.  
  3. CI(1)                      Unix Programmer's Manual                      CI(1)
  4.  
  5.  
  6. NNNAAAMMMEEE
  7.      ci - check in RCS revisions
  8.  
  9. SSSYYYNNNOOOPPPSSSIIISSS
  10.      ccciii [_o_p_t_i_o_n_s] _f_i_l_e ...
  11.  
  12. DDDEEESSSCCCRRRIIIPPPTTTIIIOOONNN
  13.      ccciii stores new revisions into RCS files.  Each file name ending in  ,,,vvv  is
  14.      taken  to  be  an  RCS  file.  All others are assumed to be working files
  15.      containing new revisions.  ccciii deposits the contents of each working  file
  16.      into  the  corresponding  RCS  file.  If only a working file is given, ccciii
  17.      tries to find the corresponding RCS file in an RCS subdirectory and  then
  18.      in  the  working  file's  directory.   For  more details, see FILE NAMING
  19.      below.
  20.  
  21.      For ccciii to work, the caller's login must be on the access list, except  if
  22.      the  access  list is empty or the caller is the superuser or the owner of
  23.      the file.  To append a new  revision  to  an  existing  branch,  the  tip
  24.      revision  on that branch must be locked by the caller.  Otherwise, only a
  25.      new branch can be created.  This restriction  is  not  enforced  for  the
  26.      owner  of  the  file  if non-strict locking is used (see rrrcccsss(1)).  A lock
  27.      held by someone else may be broken with the rrrcccsss command.
  28.  
  29.      Normally, ccciii checks whether the revision to  be  deposited  is  different
  30.      from  the  preceding one.  If it is not different, ccciii aborts the deposit,
  31.      asking beforehand if possible.  A deposit  can  be  forced  with  the  ---fff
  32.      option.
  33.  
  34.      For each revision deposited, ccciii prompts  for  a  log  message.   The  log
  35.      message should summarize the change and must be terminated by end-of-file
  36.      or by a line containing ...\ by itself.  If several files are checked in ccciii
  37.      asks whether to reuse the previous log message.  If the standard input is
  38.      not a terminal, ccciii suppresses the prompt and uses the  same  log  message
  39.      for all files.  See also ---mmm.
  40.  
  41.      The number of the deposited revision can be given by any of  the  options
  42.      ---fff, ---III, ---kkk, ---lll, ---qqq, ---rrr, or ---uuu.
  43.  
  44.      If the RCS file does not exist, ccciii creates it and deposits  the  contents
  45.      of  the working file as the initial revision (default number:  111...111).  The
  46.      access list is initialized to empty.  Instead  of  the  log  message,  ccciii
  47.      requests descriptive text (see ---ttt below).
  48.  
  49. OOOPPPTTTIIIOOONNNSSS
  50.  
  51.      ---rrr[rev]]]
  52.           assigns the revision number _r_e_v to the checked-in revision, releases
  53.           the  corresponding  lock, and deletes the working file.  This is the
  54.           default.  _r_e_v may be symbolic, numeric, or mixed.
  55.  
  56.      If _r_e_v is a revision number, it must be higher than the latest one on the
  57.      branch to which _r_e_v belongs, or must start a new branch.
  58.  
  59.      If _r_e_v is a branch rather than a revision number,  the  new  revision  is
  60.      appended  to  that  branch.  The level number is obtained by incrementing
  61.      the tip revision number of that branch.  If _r_e_v indicates a  non-existing
  62.  
  63.  
  64.                                     \*(Dt                                    1
  65.  
  66.  
  67.  
  68. CI(1)                      Unix Programmer's Manual                      CI(1)
  69.  
  70.  
  71.      branch, that branch is created with the initial revision numbered _r_e_v...111...
  72.  
  73.      If _r_e_v is omitted, ccciii tries to derive the new revision  number  from  the
  74.      caller's  last  lock.   If  the  caller  has locked the tip revision of a
  75.      branch, the new revision is appended to that branch.   The  new  revision
  76.      number  is  obtained  by  incrementing  the  tip revision number.  If the
  77.      caller locked a non-tip  revision,  a  new  branch  is  started  at  that
  78.      revision by incrementing the highest branch number at that revision.  The
  79.      default initial branch and level numbers are 111.
  80.  
  81.      If _r_e_v is omitted and the caller has no  lock,  but  owns  the  file  and
  82.      locking  is  not  set  to  _s_t_r_i_c_t,  then  the revision is appended to the
  83.      default branch (normally the trunk; see the ---bbb option of rrrcccsss(1)).
  84.  
  85.      Exception: On the trunk, revisions can be appended to the  end,  but  not
  86.      inserted.
  87.  
  88.      ---fff[rev]]]
  89.           forces a deposit; the new revision  is  deposited  even  it  is  not
  90.           different from the preceding one.
  91.  
  92.      ---kkk[rev]]]
  93.           searches the working  file  for  keyword  values  to  determine  its
  94.           revision  number,  creation date, state, and author (see cccooo(1)), and
  95.           assigns  these  values  to  the  deposited  revision,  rather   than
  96.           computing  them  locally.  It also generates a default login message
  97.           noting the login of the caller and the actual  checkin  date.   This
  98.           option is useful for software distribution.  A revision that is sent
  99.           to several sites should be checked in with the ---kkk  option  at  these
  100.           sites to preserve the original number, date, author, and state.  The
  101.           extracted  keyword  values  and  the  default  log  message  may  be
  102.           overridden  with  the  options  ---ddd,  ---mmm, ---sss, ---www, and any option that
  103.           carries a revision number.
  104.  
  105.      ---lll[rev]]]
  106.           works like ---rrr, except it performs  an  additional  cccooo\\\  ---lll  for  the
  107.           deposited  revision.   Thus,  the  deposited revision is immediately
  108.           checked out again and locked.  This is useful for saving a  revision
  109.           although one wants to continue editing it after the checkin.
  110.  
  111.      ---uuu[rev]]]
  112.           works like ---lll, except that the deposited  revision  is  not  locked.
  113.           This lets one read the working file immediately after checkin.
  114.  
  115.      ---qqq[rev]]]
  116.           quiet mode; diagnostic output is not printed.  A  revision  that  is
  117.           not  different from the preceding one is not deposited, unless ---fff is
  118.           given.
  119.  
  120.      ---III[rev]]]
  121.           interactive mode; the user is prompted and questioned  even  if  the
  122.           standard input is not a terminal.
  123.  
  124.      ---ddd[date]]]
  125.           uses _d_a_t_e for the checkin date and time.  The _d_a_t_e is  specified  in
  126.           free  format  as explained in cccooo(1).  This is useful for lying about
  127.  
  128.  
  129.                                     \*(Dt                                    2
  130.  
  131.  
  132.  
  133. CI(1)                      Unix Programmer's Manual                      CI(1)
  134.  
  135.  
  136.           the checkin date, and for ---kkk if no date is available.   If  _d_a_t_e  is
  137.           empty, the working file's time of last modification is used.
  138.  
  139.      ---mmm_m_s_g
  140.           uses the string _m_s_g as the log message for all revisions checked in.
  141.  
  142.      ---nnn_n_a_m_e
  143.           assigns the symbolic name _n_a_m_e  to  the  number  of  the  checked-in
  144.           revision.  ccciii prints an error message if _n_a_m_e is already assigned to
  145.           another number.
  146.  
  147.      ---NNN_n_a_m_e
  148.           same as ---nnn, except that it overrides a previous assignment of _n_a_m_e.
  149.  
  150.      ---sss_s_t_a_t_e
  151.           sets the state of the checked-in revision to the  identifier  _s_t_a_t_e.
  152.           The default state is EEExxxppp.
  153.  
  154.      ---ttt_f_i_l_e
  155.           writes descriptive text from the contents of the named _f_i_l_e into the
  156.           RCS  file,  deleting the existing text.  The _f_i_l_e name may not begin
  157.           with ---.
  158.  
  159.      ---ttt---_s_t_r_i_n_g
  160.           Write descriptive text from the _s_t_r_i_n_g into the RCS  file,  deleting
  161.           the existing text.
  162.  
  163.      The ---ttt option, in both its forms,  has  effect  only  during  an  initial
  164.      checkin; it is silently ignored otherwise.
  165.  
  166.      During the initial checkin, if ---ttt is not given, ccciii obtains the text  from
  167.      standard  input,  terminated by end-of-file or by a line containing ...\ by
  168.      itself.  The user is prompted for the text if  interaction  is  possible;
  169.      see ---III.
  170.  
  171.      For backward compatibility with older versions of RCS, a bare  ---ttt  option
  172.      is ignored.
  173.  
  174.      ---www_l_o_g_i_n
  175.           uses _l_o_g_i_n for the author field of the deposited  revision.   Useful
  176.           for lying about the author, and for ---kkk if no author is available.
  177.  
  178.      ---VVV_n  Emulate RCS version _n.  See cccooo(1) for details.
  179.  
  180. FFFIIILLLEEE NNNAAAMMMIIINNNGGG
  181.      Pairs of RCS files and working files may be specified in three ways  (see
  182.      also the example section of cccooo(1)).
  183.  
  184.      1) Both the RCS file and the working file are given.  The RCS  file  name
  185.      is  of the form _p_a_t_h_1///_w_o_r_k_f_i_l_e,,,vvv and the working file name is of the form
  186.      _p_a_t_h_2///_w_o_r_k_f_i_l_e where _p_a_t_h_1/// and _p_a_t_h_2/// are (possibly different or  empty)
  187.      paths and _w_o_r_k_f_i_l_e is a file name.
  188.  
  189.      2) Only the RCS file is given.  Then the working file is created  in  the
  190.      current  directory  and its name is derived from the name of the RCS file
  191.      by removing _p_a_t_h_1/// and the suffix ,,,vvv.
  192.  
  193.  
  194.                                     \*(Dt                                    3
  195.  
  196.  
  197.  
  198. CI(1)                      Unix Programmer's Manual                      CI(1)
  199.  
  200.  
  201.      3) Only the working file is given.  Then ccciii looks for an RCS file of  the
  202.      form _p_a_t_h_2///RRRCCCSSS///_w_o_r_k_f_i_l_e,,,vvv or _p_a_t_h_2///_w_o_r_k_f_i_l_e,,,vvv (in this order).
  203.  
  204.      If the RCS file is specified without a path in 1) and 2), then  ccciii  looks
  205.      for  the  RCS  file  first in the directory ...///RRRCCCSSS and then in the current
  206.      directory.
  207.  
  208. FFFIIILLLEEE MMMOOODDDEEESSS
  209.      An RCS file created by ccciii inherits the read and execute permissions  from
  210.      the  working file.  If the RCS file exists already, ccciii preserves its read
  211.      and execute permissions.  ccciii always turns off all  write  permissions  of
  212.      RCS files.
  213.  
  214. FFFIIILLLEEESSS
  215.      Several temporary files may be created.  A semaphore file is  created  in
  216.      the  directory containing the RCS file.  The effective user+group must be
  217.      able to read  the  RCS  file  and  to  search  and  write  the  directory
  218.      containing  the  RCS file.  Normally, the real user+group must be able to
  219.      read the working file and to search and write  the  directory  containing
  220.      the  working file; however, some older hosts that do not conform to Posix
  221.      1003.1-1990 cannot easily switch between real and effective  ids,  so  on
  222.      these  hosts  the  effective  user+group  is  used for all accesses.  The
  223.      effective user+group is the same as the real user+group unless your  copy
  224.      of  RCS  has  setuid  or setgid privileges.  These privileges yield extra
  225.      security if RCS files are protected so that only the effective user+group
  226.      can  write  RCS  directories.   Further  protection  can  be  achieved by
  227.      granting access only to the effective user+group.
  228.  
  229.      ccciii never changes an RCS or working file; instead, it unlinks the file and
  230.      creates  a  new  one.  This strategy breaks hard links to such files, but
  231.      does not affect symbolic links.
  232.  
  233. DDDIIIAAAGGGNNNOOOSSSTTTIIICCCSSS
  234.      For each revision, ccciii prints the RCS file,  the  working  file,  and  the
  235.      number of both the deposited and the preceding revision.  The exit status
  236.      is zero if and only if all operations were successful.
  237.  
  238. IIIDDDEEENNNTTTIIIFFFIIICCCAAATTTIIIOOONNN
  239.      Author: Walter F. Tichy.
  240.      Revision Number: 5.4; Release Date: 1990/12/04.
  241.      Copyright (c) 1982, 1988, 1989 by Walter F. Tichy.
  242.      Copyright (c) 1990 by Paul Eggert.
  243.  
  244. SSSEEEEEE AAALLLSSSOOO
  245.      co(1), ident(1), rcs(1), rcsdiff(1), rcsintro(1),  rcsmerge(1),  rlog(1),
  246.      rcsfile(5)
  247.      Walter F. Tichy, RCS--A System for Version Control, _S_o_f_t_w_a_r_e--_P_r_a_c_t_i_c_e  &
  248.      _E_x_p_e_r_i_e_n_c_e 111555, 7 (July 1985), 637-654.
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.                                     \*(Dt                                    4
  260.  
  261.